Subject: Function set 102 not applicable to APPN ENs

From: [email-masked] (Matthew Finlayson)
Date: Tue, 27 Sep 94 16:56:47 BST

Dave,

An EN must contain an independent CP LU, which must support pacing of
some description. This makes the function set applicable to ENs, and
the only question is whether it should be base or an option.

In addition, the description of function sets is rather woolly on the split
between CP, Path Control and LU function. Function sets 041 and 042 refer to
Session RU segmentation and reassembly. Segmentation is implemented in Path
Control, but reassembly is architected as part of the LU. Function set 041
is listed as being optional for an EN (and 042 is base) - indeed with HPR
support both will become base for ENs.

Our opinion is that, because of the performance benefits, 031 should be
base for ENs.

==============================================================
Matthew Finlayson                   Data Connection Limited
([email-masked])                  Telephone: +44 81 366 1177
                                    Fax:       +44 81 367 8501
==============================================================

---

From: David Bryant/HQ/3Com <[email-masked]>
Date: 27 Sep 94 11:37:17 EDT

Matthew -   Hopefully one of these will find it's way to you.  We've been 
having some problems accessing the IBM mail exploders from here.  Not being 
part of the IBM Arch group anymore, one should take my comments with the 
appropriate grain of salt, and I encourage my old brethren to correct me and 
comment freely.  Here's my $.02 worth...

You jumped around quite a bit with a lot of option sets (102, 42, 42, and 31?), 
so it's kind of hard to respond.  Let me take a shot.  

You will notice that neither LU 6.2 or the CP.LU is documented in the APPN 
Arch. Reference manual.  There is some scant documentation concerning the 
CP.LU, but no definition of how it is implemented.  This is documented in the 
LU6.2 peer protocols manual.   On the topic of function set 102 (pacing), this 
is an LU function within an EN.  Yes, there is a CP-LU but this LU is a base LU 
6.2 implementation with some required option sets.  I'm not sure any of the 
CP-LU required option sets were ever actually documented.  Option set 401 
(reliable one way brackets) is one that comes to mind that is required.  To the 
best of my knowledge, LU6.2 supports both fixed and adaptive pacing.  But the 
pacing type being used is not really exposed at the API.   So basically, the LU 
uses it if has it.  Some older LU6.2 implementations didn't have it so they 
won't use it and new LU 6.2 implementations must have it to interoperate with 
other LUs that don't have it.   Now, in the case of CP.LUs, you will find that 
the vast majority of implementations have it... so they use it. 
But we did run into a case with an OEM implementation that used a very old LU 
6.2 implementation that did not support adaptive pacing.   

Bottom line is that theoretically CP-CP sessions should be able to support both 
fixed and adaptive pacing.  Implementing this level of support would be the 
safest thing to do.  But in practicality, almost every implementation existing 
uses adaptive session level pacing.  In either case, it is an LU function and 
not an "APPN" option set per se. 

Option sets 041 and 042 fall into a bit of a different camp in the sense that 
segmentation is done in PC which is an APPN component.  And reassembly is done 
in BOTH ISR/SC and HS.  So in the case of ISR, it's an APPN function as well.  
(This is similar to pacing).    So one could claim that support for reassembly 
in "APPN" is not applicable to APPN ENs as well, since it too is an LU 
function.  Reading 041 and 042, it seems there's a bit of overlap in that both 
refer to PC segmentation to match the max BTU limit and ISR/HS reassembly.   
But such is life.

Option set 031 is CP Caps Exchange and I assume a typo??  So if you're 
proposing option set 041 should be base for ENs, I can't say I have strong 
opinion one way or the other.  But, from an EN standpoint the reassembly 
function is an LU issue and the segmentation support is a PC issue.  I'm pretty 
sure that if you indicate you support segmentation (whole BIU indicator), then 
this implies you support reassembly.   So implementation-wise, you should make 
sure your PC supports segmentation and then let the LUs indicate individually 
whether they support reassembly via the whole BIU indicator.  Remember that 
APPN nodes can also support local dependent LUs with the advent of DLUR... and 
with dependent LUs comes LUs that may not support reassembly.

Hope this helps, Dave

---

From: David Bryant/HQ/3Com <[email-masked]>
Date: 27 Sep 94 11:41:23 EDT

Hope this helps, Dave